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Abstract 


In contrast to the present Internet architecture, a path-aware internetworking architecture has 
two important properties: it exposes the properties of available Internet paths to endpoints, and 
it provides for endpoints and applications to use these properties to select paths through the 
Internet for their traffic. While this property of "path awareness" already exists in many Internet- 
connected networks within single domains and via administrative interfaces to the network 
layer, a fully path-aware internetwork expands these concepts across layers and across the 
Internet. 


This document poses questions in path-aware networking, open as of 2021, that must be answered 
in the design, development, and deployment of path-aware internetworks. It was originally 
written to frame discussions in the Path Aware Networking Research Group (PANRG), and has 
been published to snapshot current thinking in this space. 


Status of This Memo 


This document is not an Internet Standards Track specification; it is published for informational 
purposes. 


This document is a product of the Internet Research Task Force (IRTF). The IRTF publishes the 
results of Internet-related research and development activities. These results might not be 
suitable for deployment. This RFC represents the consensus of the Path Aware Networking 
Research Group of the Internet Research Task Force (IRTF). Documents approved for publication 
by the IRSG are not candidates for any level of Internet Standard; see Section 2 of RFC 7841. 


Information about the current status of this document, any errata, and howto provide feedback 
on it may be obtained at https://www.rfc-editor.org/info/rfc9217. 
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1. Introduction to Path-Aware Networking 


In the current Internet architecture, the network layer provides a best-effort service to the 
endpoints using it, without verifiability of the properties of the path between the endpoints. While 
there are network-layer technologies that attempt better-than-best-effort delivery, the interfaces 
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to these are generally administrative as opposed to endpoint exposed (e.g., Path Computation 
Element (PCE) [RFC4655] and Software-Defined Wide Area Network (SD-WAN) [MEF70] 
approaches), and they are often restricted to single administrative domains. In this architecture, 
an application can assume that a packet with a given destination address will eventually be 
forwarded toward that destination, but little else. 


A transport-layer protocol such as TCP can provide reliability over this best-effort service, anda 
protocol above the network layer, such as Transport Layer Security (TLS) [RFC8446], can 
authenticate the remote endpoint. However, little, if any, explicit information about the path is 
available to the endpoints, and any assumptions made about that path often do not hold. These 
sometimes have serious impacts on the application, as in the case with BGP hijacking attacks. 


By contrast, in a path-aware internetworking architecture, endpoints can select or influence the 
path(s) through the network used by any given packet or flow. The network and transport layers 
explicitly expose information about the path or paths available to the endpoints and to the 
applications running on them, so that they can make this selection. The Application-Layer Traffic 
Optimization (ALTO) protocol [RFC7285] can be seen as an example of a path-awareness 
approach implemented in transport-layer terms on the present Internet protocol stack. 


Path selection provides explicit visibility and control of network treatment to applications and 
users of the network. This selection is available to the application-, transport-, and/or network- 
layer entities at each endpoint. Path control at the flow and subflow level enables the design of 
new transport protocols that can leverage multipath connectivity across disjoint paths through 
the Internet, even over a single physical interface. When exposed to applications, or to end users 
through a system configuration interface, path control allows the specification of constraints on 
the paths that traffic should traverse, for instance to confound passive surveillance in the 
network core [RFC7624]. 


We note that this property of "path awareness" already exists in many Internet-connected 
networks within single domains. Indeed, much of the practice of network engineering using 
encapsulation at layer 3 can be said to be "path aware’ in that it explicitly assigns traffic at tunnel 
endpoints to a given path within the network. Path-aware internetworking seeks to extend this 
awareness across domain boundaries without resorting to overlays, except as a transition 
technology. 


This document presents a snapshot of open questions in this space that will need to be answered 
in order to realize a path-aware internetworking architecture; it is published to further frame 
discussions within and outside the Path Aware Networking Research Group, and is published with 
the rough consensus of that group. 
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1.1. Definitions 


For purposes of this document, "path-aware networking" describes endpoint discovery of the 
properties of paths they use for communication across an internetwork, and endpoint reaction 
to these properties that affects routing and/or data transfer. Note that this can and already does 
happen to some extent in the current Internet architecture; this definition expands current 
techniques of path discovery and manipulation to cross administrative domain boundaries and 
up to the transport and application layers at the endpoints. 


Expanding on this definition, a "path-aware internetwork" is one in which endpoint discovery of 
path properties and endpoint selection of paths used by traffic exchanged by the endpoint are 
explicitly supported regardless of the specific design of the protocol features that enable this 
discovery and selection. 


A "path", for the purposes of these definitions, is abstractly defined as a sequence of adjacent path 
elements over which a packet can be transmitted, where the definition of "path element" is 
technology dependent. As this document is intended to pose questions rather than answer them, 
it assumes that this definition will be refined as part of the answer to the first two questions it 
poses about the vocabulary of path properties and how they are disseminated. 


Research into path-aware internetworking covers any and all aspects of designing, building, and 
operating path-aware internetworks or the networks and endpoints attached to them. This 
document presents a collection of research questions to address in order to make a path-aware 
Internet a reality. 


2. Questions 


Realizing path-aware networking requires answers to a set of open research questions. This 
document poses these questions as a starting point for discussions about how to realize path 
awareness in the Internet and to direct future research efforts within the Path Aware Networking 
Research Group. 


2.1. A Vocabulary of Path Properties 


The first question: how are paths and path properties defined and represented? 


In order for information about paths to be exposed to an endpoint, and for the endpoint to make 
use of that information, it is necessary to define a common vocabulary for paths through an 
internetwork and properties of those paths. The elements of this vocabulary could include 
terminology for components of a path and properties defined for these components, for the 
entire path or for subpaths of a path. These properties may be relatively static, such as the 
presence of a given node or service function on the path, as well as relatively dynamic, suchas 
the current values of metrics such as loss and latency. 
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This vocabulary and its representation must be defined carefully, as its design will have impacts 
on the properties (e.g., expressiveness, scalability, and security) of a given path-aware 
internetworking architecture. For example, a system that exposes node-level information for the 
topology through each network would maximize information about the individual components 
of the path at the endpoints, at the expense of making internal network topology universally 
public, which may be in conflict with the business goals of each network's operator. Furthermore, 
properties related to individual components of the path may change frequently and may quickly 
become outdated. However, aggregating the properties of individual components to distill end-to- 
end properties for the entire path is not trivial. 


2.2. Discovery, Distribution, and Trustworthiness of Path Properties 


The second question: how do endpoints and applications get access to accurate, useful, and 
trustworthy path properties? 


Once endpoints and networks have a shared vocabulary for expressing path properties, the 
network must have some method for distributing those path properties to the endpoints. 
Regardless of how path property information is distributed, the endpoints require a method to 
authenticate the properties in order to determine that they originated from and pertain to the 
path that they purport to. 


Choices in distribution and authentication methods will have impacts on the scalability of a path- 
aware architecture. Possible dimensions in the space of distribution methods include in band 
versus out of band, push versus pull versus publish subscribe, and so on. There are temporal issues 
with path property dissemination as well, especially with dynamic properties, since the 
measurement or elicitation of dynamic properties may be outdated by the time that information 
is available at the endpoints, and interactions between the measurement and dissemination 
delay may exhibit pathological behavior for unlucky points in the parameter space. 


2.3. Supporting Path Selection 


The third question: how can endpoints select paths to use for traffic in a way that can be trusted 
by the network, the endpoints, and the applications using them? 


Access to trustworthy path properties is only half of the challenge in establishing a path-aware 
architecture. Endpoints must be able to use this information in order to select paths for specific 
traffic they send. As with the dissemination of path properties, choices made in path-selection 
methods will also have an impact on the trade-off between scalability and expressiveness of a 
path-aware architecture. One key choice here is between in-band and out-of-band control of path 
selection. Another is granularity of path selection (whether per packet, per flow, or per larger 
aggregate), which also has a large impact on the scalability/expressiveness trade-off. Path 
selection must, like path property information, be trustworthy, such that the result of a path 
selection at an endpoint is predictable. Moreover, any path-selection mechanism should aim to 
provide an outcome that is not worse than using a single path or selecting paths at random. 
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Path selection may be exposed in terms of the properties of the path or the identity of elements of 
the path. In the latter case, a path may be identified at any of multiple layers (e.g., routing domain 
identifier, network-layer address, higher-layer identifier or name, and so on). In this case, care 
must be taken to present semantically useful information to those making decisions about which 
path(s) to trust. 


2.4. Interfaces for Path Awareness 


The fourth question: how can interfaces among the network, transport, and application layers 
support the use of path awareness? 


In order for applications to make effective use of a path-aware networking architecture, the 
control interfaces presented by the network and transport layers must also expose path 
properties to the application in a useful way, and provide a useful set of paths among which the 
application can select. Path selection must be possible based not only on the preferences and 
policies of the application developer, but of end users as well. Also, the path-selection interfaces 
presented to applications and end users will need to support multiple levels of granularity. Most 
applications’ requirements can be satisfied with the expression of path-selection policies in terms 
of properties of the paths, while some applications may need finer-grained, per-path control. 
These interfaces will need to support incremental development and deployment of applications, 
and provide sensible defaults, to avoid hindering their adoption. 


2.5. Implications of Path Awareness for the Transport and Application 
Layers 


The fifth question: how should transport-layer and higher-layer protocols be redesigned to work 
most effectively over a path-aware networking layer? 


In the current Internet, the basic assumption that at a given time all traffic for a given flow will 
receive the same network treatment and traverse the same path or equivalent paths often holds. 
In a path-aware network, this assumption is more easily violated. The weakening of this 
assumption has implications for the design of protocols above any path-aware network layer. 


For example, one advantage of multipath communication is that a given end-to-end flow can be 
"sprayed" along multiple paths in order to confound attempts to collect data or metadata from 
those flows for pervasive surveillance purposes [RFC7624]. However, the benefits of this approach 
are reduced if the upper-layer protocols use linkable identifiers on packets belonging to the same 
flow across different paths. Clients may mitigate linkability by opting to not reuse cleartext 
connection identifiers, such as TLS session IDs or tickets, on separate paths. The privacy- 
conscious strategies required for effective privacy in a path-aware Internet are only possible if 
higher-layer protocols such as TLS permit clients to obtain unlinkable identifiers. 


2.6. Whatis an Endpoint? 


The sixth question: how is path awareness (in terms of vocabulary and interfaces) different when 
applied to tunnel and overlay endpoints? 
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The vision of path-aware networking articulated so far makes an assumption that path 
properties will be disseminated to endpoints on which applications are running (terminals with 
user agents, servers, and so on). However, incremental deployment may require that a path- 
aware network "core" be used to interconnect islands of legacy protocol networks. In these cases, 
it is the gateways, not the application endpoints, that receive path properties and make path 
selections for that traffic. The interfaces provided by this gateway are necessarily different than 
those a path-aware networking layer provides to its transport and application layers, and the 
path property information the gateway needs and makes available over those interfaces may 
also be different. 


2.7. Operating a Path-Aware Network 


The seventh question: how can a path-aware network in a path-aware internetwork be effectively 
operated, given control inputs from network administrators, application designers, and end 
users? 


The network operations model in the current Internet architecture assumes that traffic flows are 
controlled by the decisions and policies made by network operators as expressed in interdomain 
and intradomain routing protocols. In a network providing path selection to the endpoints, 
however, this assumption no longer holds, as endpoints may react to path properties by selecting 
alternate paths. Competing control inputs from path-aware endpoints and the routing control 
plane may lead to more difficult traffic engineering or non-convergent forwarding, especially if 
the endpoints' and operators’ notion of the "best" path for given traffic diverges significantly. The 
degree of difficulty may depend on the fidelity of information made available to path-selection 
algorithms at the endpoints. Explicit path selection can also specify outbound paths, while BGP 
policies are expressed in terms of inbound traffic. 


Aconcept for path-aware network operations will need to have clear methods for the resolution 
of apparent (if not actual) conflicts of intent between the network's operator and the path 
selection at an endpoint. It will also need a set of safety principles to ensure that increasing path 
control does not lead to decreasing connectivity; one such safety principle could be "the 
existence of at least one path between two endpoints guarantees the selection of at least one path 
between those endpoints." 


2.8. Deploying a Path-Aware Network 


The eighth question: how can the incentives of network operators and end users be aligned to 
realize the vision of path-aware networking, and how can the transition from current ("path- 
oblivious") to path-aware networking be managed? 
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The vision presented in the introduction discusses path-aware networking from the point of view 
of the benefits accruing at the endpoints, to designers of transport protocols and applications as 
well as to the end users of those applications. However, this vision requires action not only at the 
endpoints but also within the interconnected networks offering path-aware connectivity. While 
the specific actions required are a matter of the design and implementation of a specific 
realization of a path-aware protocol stack, it is clear that any path-aware architecture will 
require network operators to give up some control of their networks over to endpoint-driven 
control inputs. 


Here, the question of apparent versus actual conflicts of intent arises again: certain network 
operation requirements may appear essential but are merely accidents of the interfaces provided 
by current routing and management protocols. For example, related (but adjacent) to path- 
aware networking, the widespread use of the TCP wire image [RFC8546] in network monitoring 
for DDoS prevention appears in conflict with the deployment of encrypted transports, only 
because path signaling [RFC8558] has been implicit in the deployment of past transport protocols. 


Similarly, incentives for deployment must show how existing network operation requirements 
are met through new path selection and property dissemination mechanisms. 


The incentives for network operators and equipment vendors need to be made clear, in terms of 
a plan to transition [RFC8170] an internetwork to path-aware operation, one network and 
facility at a time. This plan to transition must also take into account that the dynamics of path- 
aware networking early in this transition (when few endpoints and flows in the Internet use path 
selection) may be different than those later in the transition. 


Aspects of data security and information management in a network that explicitly radiates more 
information about the network's deployment and configuration, and implicitly radiates 
information about endpoint configuration and preference through path selection, must also be 
addressed. 


3. IANA Considerations 


This document has no IANA actions. 


4. Security and Privacy Considerations 


This document poses questions about path-aware internetworking; the answers are a matter for 
future research, and security considerations for those answers would be included in the 
corresponding RFCs that describe them. While each of these questions is to a lesser or greater 
degree relevant to the security and privacy of users of a path-aware network, questions of 
discovery and trustworthiness (Section 2.2) are most security-relevant. 
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